Managing deferred account creation and software access

ABSTRACT

The present disclosure is directed towards systems and methods for using a software as a service (“SaaS”) product. The systems and methods request, in response to receiving a request to purchase a software as a service product, a user identifier. Additionally, in response to receiving the user identifier, the systems and methods enable a completed purchase of the SaaS product with a provisional account associated with the user identifier. Furthermore, the systems and methods prevent use of the software as a service product through the provisional account and, in response to a completed purchase of the software as a service product, request a creation of a user credential. Upon receiving the user credential, the systems and methods convert the provisional account into a permanent account associated with the user identifier and user credential and enable use of the SaaS product through the permanent account.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/583,228, filed May 1, 2017, which is hereby incorporated by referencein its entirety.

BACKGROUND

The Internet has played an influential role in developing electroniccommerce. Many businesses have established websites to promote theirproducts to potential consumers. Typically, the website includes a userinterface that allows consumers to select items they wish to purchaseand place them into a virtual shopping cart while they continue tobrowse. After the consumer has completed browsing and/or selecting otheritems on the website and is ready to “checkout,” the consumer completesthe ordering process to purchase the items. Conventionally, during thecheckout phase, the website directs the consumer to another web page(e.g., a checkout page) where the consumer provides payment information.Furthermore, typically, the website requires a user to login to thewebsite and/or create an account with the website in order to complete apurchase.

By requiring a consumer to login and/or create an account with amerchant website, the checkout process can be time extensive and canprovide friction between the consumer and the merchant (e.g., requiringa user to create a username, password, provide payment information,address, etc.). This is especially true with mobile devices, whichpresent more difficulty in creating usernames and passwords. As aresult, in some instances, having to login and/or create an accountprior to making a purchase with the merchant website can inhibit (e.g.,deter and/or prevent) purchases from the consumer. Some attempts tomediate the above issues include guest checkout services, which allow aconsumer to purchase a product from a merchant website without having tocreate an account with the merchant website.

However, such guest checkout services fail to provide adequate solutionswhen dealing with software as a service (SaaS) products (e.g., productssuch as software licensed on a subscription basis and centrally hosted),which typically require login credentials (e.g., an account and/orauthentication) to operate and use the SaaS products. Additionally, suchSaaS products conventionally require an account with the merchant systemproviding (e.g., hosting) the SaaS products, which guest checkoutservices do not require. Furthermore, the merchants providing such SaaSproducts typically require email verification to determine correctpricing, corporate accounts, shared licenses, permissions, etc. thatguest checkout services do not require.

Accordingly, these and other disadvantages exist with respect toconventional systems.

BRIEF SUMMARY

The various embodiments described below provide benefits and/or solveone or more of the foregoing or other problems in the art with systemsand methods for providing software products to a user in a streamlinedprocess that defers the need for users to create a full user account(e.g., setting a password) prior to making a purchase. In particular,the systems and methods enable a user to purchase a product withoutcreating a username and password combination. In one or moreembodiments, the systems and methods create a provisional account forthe user and enable the user to purchase a software product (e.g., aSaaS product) using the provisional account without creating a full useraccount. Moreover, upon a completed purchase of the software product,the systems and methods require the user to create a full user accountprior to enabling use of the purchased software product. In response tothe user creating a username and password combination, the systems andmethods convert the provisional account to a permanent account.Accordingly, the systems and methods avoid at least some of the frictionassociated with conventional purchase processes of software products.

Additional features and advantages of the embodiments will be set forthin the description that follows, and in part will be obvious from thedescription, or may be learned by the practice of such exampleembodiments. The features and advantages of such embodiments may berealized and obtained by means of the instruments and combinationsparticularly pointed out in the appended claims. These, and otherfeatures, will become more fully apparent from the following descriptionand appended claims, or may be learned by the practice of such exampleembodiments as set forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments will be described and explained with additionalspecificity and detail through the use of the accompanying drawings inwhich:

FIG. 1 illustrates a schematic representation of an environment withinwhich merchant system can operate in accordance with one or moreembodiments of the present disclosure;

FIGS. 2A-2D illustrate a sequence flow diagram that a merchant systemcan utilize to enable use of a product in accordance with one or moreembodiments;

FIGS. 3A-3G illustrate a plurality of schematic representations ofgraphical user interfaces of the merchant system for enabling use of aproduct according to one or more embodiments of the present disclosure;

FIG. 4 illustrates an algorithm that a merchant system can utilize toperform a step for preventing use of the software as a service productthrough the provisional account in accordance with one or moreembodiments;

FIG. 5 illustrates a flowchart of an example method for enabling adownload of a software as a service product according to one or moreembodiments of the present disclosure;

FIG. 6 illustrates a flowchart of another example method for enabling adownload of a software as a service product according to one or moreembodiments of the present disclosure; and

FIG. 7 illustrates a block diagram of an example computing device inaccordance with one or more embodiments of the present disclosure.

DETAILED DESCRIPTION

The various embodiments described herein provide a merchant system forproviding software products to a user in a streamlined process thatdefers the need for users to create a full user account (e.g., setting apassword) prior to making a purchase. In particular, in one or moreembodiments, the merchant system creates a provisional account for theuser and enables the user to purchase a software product (e.g., a SaaSproduct) using the provisional account without setting a password. Priorto enabling use of the purchased software product, the merchant systemrequires the user to provide a password, with which the merchant systemconverts the provisional account into a permanent account. The merchantsystem then enables use of the purchased software product in connectionwith the permanent account.

As noted above, in some embodiments, the merchant system enables a userto purchase but not use a SaaS product via a provisional account, whichonly requires a user to input a user identifier (e.g., username). Forexample, in response to receiving a request to purchase a SaaS product,the merchant system can request a user identifier (e.g., user name) fromthe user. Furthermore, in response to receiving the user identifier fromthe user, the merchant system can determine whether the user identifieris associated with a preexisting account of the merchant system.Moreover, upon determining that the user identifier is not associatedwith a preexisting account of the merchant system, the merchant systemcan create a provisional account of the merchant system, which enablesthe user to purchase the SaaS product without creating a user identifierand user credential (e.g., username and password) combination. However,as noted above, the provisional account does not permit a user to usethe SaaS product without performing an additional claiming action (e.g.,verifying an email, creating a password, etc.)

Because the merchant system enables the user to purchase the SaaSproduct via a provisional account while only requiring a useridentifier, the merchant system provides a quick, efficient, and moresimplified checkout process for a user in comparison to conventionalsystems. Furthermore, because the merchant system provides a moresimplified checkout process, the merchant system reduces frictionbetween the user and the merchant system during a checkout process incomparison to conventional systems. As a result, the merchant systemprovides a more suitable checkout process for mobile devices incomparison to conventional systems. Moreover, as will be appreciated byone or ordinary skill in the art, by simplifying the checkout process,the merchant system of the present disclosure may provide a moreenjoyable experience for new users, which, in turn, results in increasedsales and revenue.

As mentioned briefly above, the merchant system enables a user to usethe SaaS product via a permanent account, which requires a user to inputboth a user identifier and a user credential. For example, the merchantsystem can enable the purchase of the SaaS product through theprovisional account and, then, the merchant system can require the userto perform a claiming action in order to use the purchase SaaS product.For instance, the merchant system can require the user to create a usercredential (e.g., password) and/or verify an email address (e.g., createa permanent account with the merchant system). In particular, uponfacilitating a purchase of the SaaS product via the provisional account,the merchant system can provide a communication to the user (e.g., via aclient device) instructing the user to create a user credential.Furthermore, until the user completes the claiming action, the merchantsystem can prevent the user from using (e.g., downloading and/oroperating) the SaaS product. Because the merchant system enables theuser to purchase the SaaS product via a provisional account while onlyrequiring a user identifier but requires the user to complete a claimingaction before using the product, the merchant system simplifies thecheckout process while still requiring needed information for using theSaaS product (e.g., an established account with the merchant system).

Furthermore, because the merchant system of the present disclosureprovides SaaS products to a user in a streamlined process while stillacquiring required credentials to use the SaaS products, as describedabove, the merchant system provides improvements in the performance of acomputer system. For example, because the merchant system only requiresa user identifier instead of requiring a user identifier and a usercredential (e.g., a full login) during a checkout process, the merchantsystem reduces required processing power, memory, etc. Therefore, themerchant system reduces required processing power, memory, andcommunication resources needed to facilitate purchasing processes.Accordingly, the merchant system results in less data transfer and databandwidth usage for a computer/communication system. In other words, themerchant system results in less required processing power andcommunication bandwidth in comparison to conventional systems. As aresult, the merchant system of the present disclosure, in comparison toconventional systems, is a more appropriate system for mobile devices.

As used herein, the term “provisional account” refers to an account withthe merchant system (e.g., an established digital relationship between auser and the merchant system) that permits a user to purchase a product(e.g., a service, a software product, etc.) from the merchant system butdoes not enable use of the product. As used herein the term “use” whenused in connection with a product of the merchant system can refer toone or more of operating the product (e.g., operating a softwareproduct) and downloading the product (e.g. downloading a softwareproduct). For example, a provisional account refers to an account withthe merchant system that does not allow full use of a product of themerchant system. In some instances, the provisional account can bedesignated as provisional (e.g., can be in a provisional state) via anassigned status identifier within an identification system.

As used herein, the term “permanent account” or “full user account”refers to an account with the merchant system that permits a user topurchase a product and enables use of a purchased product through thepermanent account. As is discussed in greater detail below, in someinstances, the use may be limited, and in other instances, the use maybe complete depending on how the permanent account was created. In someinstances, the permanent account can be designated as permanent (e.g.,can be in a permanent state) via an assigned status identifier within anidentification system.

To provide some of the benefits discussed above, one or more embodimentsof the merchant system include an identification system that maintains astatus of user accounts. In particular, the identification system mapsuser identifiers to account statuses (e.g., provisional or permanent).As mentioned above, provisional and permanent accounts each havedifferent levels of permissions (e.g., access to software product use ornot). Each time a user enters a user identifier into aproduct/application/website associated with the merchant system, themerchant system queries the identification system to verify a status ofany account associated with the user identifier. If the status isprovisional, prevents use of one or more software products until theaccount is converted into a permanent account. Furthermore, uponidentifying an account as a provisional account, the merchant system canprompt the user to perform a claiming process (e.g., providing apassword) in order to convert the provisional account into a permanentaccount. The identification system is remote from the client device. Assuch, the merchant system can verify or monitor any use of an accountassociated with the user identifier irrespective of the device orbrowser session using the user identifier. Furthermore, because themerchant system creates the provisional account and associates theprovisional account with the user identifier (e.g., creates a basicaccount associated for the user), the claiming action can be performedfrom a different client device and/or during a different browsingsession (i.e., web browser session) by providing the user identifier. Inother words, the individual actions of purchasing the SaaS product(e.g., creating a provisional account associated with the useridentifier) and creating a permanent account associated with thepurchase and the user identifier are client device and/or browsingsession agnostic. As a result, the merchant system is advantageous overconventional purchasing systems (e.g., guest checkouts), which aretypically browsing session specific, and as a result, are client devicespecific.

FIG. 1 illustrates a schematic diagram of an environment 100 in which amerchant system can operate according to one or more embodiments of thepresent disclosure. As illustrated, the environment 100 includes aclient device 104, at least one server 101 including a merchant system102, and a network 108. The merchant system 102 and the client device104 can communicate via the network 108. The network 108 may include oneor more networks, such as the Internet, and can use one or morecommunications platforms or technologies suitable for transmitting dataand/or communication signals. Although FIG. 1 illustrates a particulararrangement of the client device 104, the server 101, and the network108, various additional arrangements are possible. For example, theserver 101 and, accordingly, the merchant system 102, can directlycommunicate with the client device 104, bypassing the network 108.

As illustrated in FIG. 1, a user 110 can interface with the clientdevice 104, for example, to communicate with the server 101 and toutilize the merchant system 102 to purchase and use a product such as asoftware as a service (“SaaS”) product (referred to hereinafter as a“product”). The user 110 can be an individual (i.e., human user), abusiness, a group, or any other entity. Although FIG. 1 illustrates onlyone user 110 associated with the client device 104, the environment 100can include any number of a plurality of users that each interact withthe environment 100 using a corresponding client device.

In some embodiments, the merchant system 102 can include a systemassociated with an entity such as a service provider, which providesgoods and/or services to customers (e.g., user 110). In one or moreembodiments, the merchant system 102 can provide products for purchaseover the Internet via one or more websites or native applications usinga client device (e.g., via the client device 104). As is discussed ingreater detail below, in some embodiments, the products can includesoftware (e.g., SaaS), videos, images, access to software (e.g.,licenses), access to databases, etc. Furthermore, in some embodiments,the merchant system 102 can host the products. In some embodiments, themerchant system 102 may have physical retail locations in addition toone or more websites.

Additionally, the merchant system 102 can manage access to the productsoffered and sold by the merchant system 102. For example, the merchantsystem 102 can allow users to purchase products without requiring theuser to fully create an account with the merchant system 102 (e.g.,without creating a username and password). However, as will be discussedin greater detail in regard to FIGS. 2A-2D, the merchant system 102 canrequire a user to fully create an account (e.g., a combination of ausername and password) in order to utilize a purchased product from themerchant system 102. For example, the merchant system 102 can verifywhether an account of the user has sufficient permissions (e.g., is theright type of account) to use a product after purchasing the product.

As illustrated, in some embodiments, the merchant system 102 can includean identification system 106 having a database 114. As is described ingreater detail below in regard to FIGS. 2A-2E, the merchant system 102can utilize (e.g., query) the identification system 106 when determiningwhether to provide access to a product for a given user. In someembodiments, the merchant system 102 can include an API gateway.Furthermore, the API gateway can provide access control (i.e., filteringtraffic such that only authenticated and/or authorized traffic accessthe merchant system 102) and/or security filtering between the merchantsystem 102 and the identification system 106. For example, as isdiscussed in greater detail below, in some embodiments, the merchantsystem 102 can query the identification system 106 (via the API gateway)to determine, based on a provided user identifier, whether a user has aprovisional account (e.g., a limited account) with the merchant system102 or a permanent account with the merchant system 102.

Furthermore, although the identification system 106 is illustrated asbeing part of the merchant system 102, the disclosure is not so limited.Rather, in some embodiments, the identification system 106 can beseparate from the merchant system 102. For example, the identificationsystem 106 can be located on separate servers and/or can be associatedwith a third-party system.

In some embodiments, the client device 104 includes a client application112 installed thereon. In some embodiments, the client application 112can be associated with the merchant system 102. For example, the clientapplication 112 allows the client device 104 to directly or indirectlyinterface with the merchant system 102. The client application 112 alsoenables the user 110 to purchase and/or access products via the merchantsystem 102 and the client device 104 to receive (e.g., downloadproducts) to the client device 104. For example, the client application112 can include a web browsing application and/or a native application.

Both the client device 104 and the server 101 can represent varioustypes of computing devices with which users can interact. For example,the client device 104 and/or the server 101 can be a mobile device(e.g., a cell phone, a smartphone, a PDA, a tablet, a laptop, a watch, awearable device, etc.). In some embodiments, however, the client device104 and/or server 101 can be a non-mobile device (e.g., a desktop orserver). Additional details with respect to the client device 104 andthe server 101 are discussed below with respect to FIG. 7.

FIGS. 2A-2D illustrate a sequence-flow diagram 200 that a merchantsystem 102 can utilize to enable a purchase of a product (e.g., a SaaSproduct) through a provisional account and requiring a creation of apermanent account to use the product. The client device 104 and merchantsystem 102 shown in FIGS. 2A-2D may be example embodiments of the clientdevice 104 and merchant system 102 described in regard to FIG. 1.

A client device 104 can detect one or more user interactions requestingto purchase a product from a merchant system 102. For instance, theclient device 104 can detect a user interaction requesting to purchase aproduct via the client application 112 (e.g., a web browsing applicationdisplaying a store front of the merchant system 102). For example, theclient application 112 (e.g., a web browser and/or application specificto the merchant system) can detect the user interaction requesting topurchase a product. In one or more embodiments, the user interaction mayinclude an interaction with a “buy now” button or other user input thatis part of a purchasing work flow. In additional embodiments, the userinteraction may include adding a product to an electronic cart of awebsite associated with the merchant system 102 and proceeding tocheckout page of the website. As used herein, the terms “userinteraction” mean a single interaction, or combination of interactions,received from a user by way of one or more input devices (e.g., a touchscreen display, a keyboard, a mouse, etc.) of the client device 104.Furthermore, the user interaction may include one or more of clicking,tapping, or otherwise selecting elements (e.g., letters and/orcharacters) to request to purchase a product. As noted above, in one ormore embodiments, the product may include one or more of a SaaS product,a video, an audio file, an image, access to software (e.g., licenses),etc. Furthermore, the product can include access to databases such as,for example, image and/or video databases.

In connection with a request to purchase a product, the clientapplication 112 requests a user identifier from the client device. Insome embodiments, the application 112 can request a user identifierincluding one or more of an email address, a username, a logincredential, etc. Furthermore, in some embodiments, the request for theuser identifier can include a request to create (e.g., choose, select,assign, etc.) a user identifier. In one or more embodiments, the clientapplication 112 can request the user identifier via a web browser and/ora native application specific to the merchant system. For example, theclient application 112 can request the user identifier during a checkoutprocess of the user with the merchant system 102.

The client device 104 displays the request to the user 110. For example,the client device 104 can display the request within the clientapplication 112. For instance, the client application 112 can displaythe request as a message and a corresponding input area within agraphical user interface (“GUI”) of client application 112 and/or themerchant system 102 (e.g., a GUI of the checkout process of the merchantsystem 102).

As shown in FIG. 2A, the merchant system 102 receives the useridentifier in act 204. For example, upon detecting the user interactioninputting the user identifier, the client device 104 and/or the clientapplication 112 can provide the user identifier (e.g., a data packageincluding the user identifier) to the merchant system 102. In one ormore embodiments, the merchant system 102 can receive the useridentifier through the network 108.

In response to receiving the user identifier, as illustrated in FIG. 2A,the merchant system 102 determines whether the user identifier isassociated with a preexisting account of the merchant system. Forexample, the merchant system 102 can query (e.g., via an API call) theidentification system 106 to determine whether the user identifier isassociated with a preexisting provisional account or a permanent accountof the merchant system 102. In some embodiments, the identificationsystem 106 can query the database 114 to determine whether the useridentifier is associated with a preexisting account of the merchantsystem 102. For instance, the merchant system 102 can query theidentification system 106, which, in turn, can compare the received useridentifier with user identifiers associated with preexisting accounts ofthe merchant system 102 within the database 114. The identificationsystem 106 can communicate with the merchant system 102 as to whetherthe user identifier is associated with a preexisting account.

If the merchant system 102 determines that the user identifier isassociated with a preexisting permanent account, as is discussed ingreater detail below in regard to FIG. 4, the merchant system 102 canrequest that the user input a user credential (e.g., ask for a password)associated with the user identifier. For example, the merchant system102 can require the user to login into the merchant system 102 via theuser identifier and user credential.

If the merchant system 102 determines that the user identifier isassociated with a preexisting provisional account, as is discussed ingreater detail below in regard to FIG. 4, the merchant system 102 canprovide instructions to the user on how to create a user credential(e.g., set a password). For example, the merchant system 102 can provideinstructions within a client application GUI and/or a merchant systemGUI on how to create a user credential (e.g., set a password). As isdiscussed in greater detail below, in some embodiments, the instructionscan direct the user to create a user credential through a link in apreviously sent email. In other embodiments, the instructions can directthe user to create a user credential within the client application GUIand/or the merchant system GUI (e.g., within the current web browsingsession). In yet other embodiments, the instructions can provide anoption to resend the previously sent email with instructions.Regardless, the merchant system 102 requires the user to create a usercredential prior to providing access to (e.g., use of) a purchasedproduct.

If the merchant system 102 determines that the received user identifieris not associated with a preexisting account of the merchant system, themerchant system 102 creates a provisional account of the merchant system102 associated with the user identifier, as shown in act 216 of FIG. 2A.In one or more embodiments, the merchant system 102 can communicate withthe identification system 106, and the identification system 106 cancreate the provisional account within the database 114 of the merchantsystem 102. In some embodiments, the merchant system 102 can create theprovisional account by creating a data package establishing (e.g.,defining) a provisional relationship between the user and the merchantsystem 102 and associating the user identifier with the data packagewithin the database 114 of the identification system 106. For example,the provisional account can allow a user to purchase a product whiledenying use of the product.

As mentioned above, the merchant system 102 creates a provisionalaccount that enables (e.g., permits) a user to purchase a productthrough the provisional account without requiring a creation of a usercredential (e.g., password). For example, the provisional account can bein a state that does not allow (e.g., enable) a user credential (e.g.,password) to be entered during a purchase process or a login attempt.

Furthermore, as noted above, the merchant system 102 creates theprovisional account such that the provisional account is not be capableof utilizing (i.e., using) a purchased product of the merchant system.For instance, in some embodiments, when creating the provisionalaccount, the merchant system 102 can associate a provisional identifierwith the provisional account within the database 114 of theidentification system 106. In other words, the merchant system 102 cantag (e.g., mark or label) the provisional account with the provisionalidentifier (e.g., tag) within the database 114 of the identificationsystem 106. Furthermore, based on the provisional identifier of theprovisional account, the merchant system 102 may not allow a usercredential to be entered during a login attempt and may not allow use ofthe product through the provisional account. As will be discussed ingreater detail below, the provisional account requires a user to performadditional actions (e.g., claiming actions) to create a permanentaccount and to create a user credential in order to use the purchasedproduct.

In some embodiments, creating the provisional account can furtherinclude reserving the received user identifier for the provisionalaccount within the database 114 of the identification system 106.Furthermore, the merchant system 102 can create a data packageassociated with the user identifier that defines the access of theprovisional account of the user and can store the data package withinthe database 114 of the identification system 106.

Referring again to act 214 of FIG. 2A, although the merchant system isdescribed herein as determining whether a user identifier is associatedwith a preexisting account within a purchase process (e.g., acts 204-212of FIG. 2A), the disclosure is not so limited. Rather, for example, themerchant system 102 can determine whether a user identifier received viaa login attempt (e.g., a login attempt to the merchant system 102) isassociated with a preexisting account.

In addition to creating a provisional account associated with the useridentifier, the merchant system 102 requests payment information fromthe user, as shown in act 218 of FIG. 2A. For example, in someembodiments, the merchant system 102 can request payment cardinformation, an address associated with the payment card, etc. Inadditional embodiments, the merchant system 102 can request credentialsfor an online payment service (e.g., PAYPAL, GOOGLE WALLET, etc.).Requesting the payment information from the user is described in greaterdetail below in regard to FIGS. 3C and 3D.

Upon receiving the request for payment information, the clientapplication 112 and/or client device 104 detects a user interactioninputting payment information. For example, the client application 112of the client device 104 detects a user interaction inputting paymentcard details and/or online payment service credentials within the clientapplication 112 (e.g., the client application GUI). The client device104 detecting a user interaction inputting payment information isdescribed in greater detail below in regard to FIGS. 3C and 3D.

As shown in FIG. 2B, upon the client device 104 detecting the userinteraction inputting the payment information, the merchant system 102receives the payment information, as shown in act 222. For example, upondetecting the user interaction inputting the payment information, theclient device 104 and/or the client application 112 can provide thepayment information (e.g., a data package including the paymentinformation) to the merchant system 102. In one or more embodiments, themerchant system 102 can receive the payment information through thenetwork 108.

Although the merchant system 102 is described herein as requesting andreceiving payment information after creating the provisional accountassociated with the user identifier, the disclosure is not so limited.For example, in some embodiments, the merchant system 102 can requestthe payment information and can receive the payment information prior tocreating the provisional account associated with the user identifier.For instance, the merchant system 102 can request the paymentinformation upon determining that the user identifier is not associatedwith the preexisting account of the merchant system 102.

Regardless, in response to receiving the payment information, asillustrated in FIG. 2B, the merchant system 102 associates the paymentinformation with the provisional account associated with the useridentifier, as shown in act 224. For instance, the merchant system 102can create a data package including the payment information (e.g.,payment card details, online payment service details, etc.) and canassociate the payment information with the provisional accountassociated with the user identifier within the database 114 of theidentification system 106.

In some embodiments, upon receiving the payment information, themerchant system 102 can further perform an Address Verification Service(AVS) check (e.g., compare a numerical portion of the cardholder'sbilling address (street number and ZIP code) against information in apayment card issuing bank's databases) and a Card Security Code (CVV)check (e.g., verifying that an input 3- or 4-digit number is correct) asa fraud prevention measure. In some embodiments, the merchant system 102can perform the fraud prevention measure prior to creating theprovisional account.

Upon receiving the payment information and associating the paymentinformation with the provisional account, the merchant system 102enables (e.g., authorizes) a purchase of the product by the user throughthe provisional account, as show in act 226 of FIG. 2B. For example, themerchant system 102 enables a user to interact with a selectable element(e.g., a confirm purchase button) to initiate and/or complete a purchaseof the product.

In response to the merchant system 102 enabling a purchase of theproduct, the client application 112 and/or client device 104 detects auser interaction causing a purchase of the product. For example, theclient application 112 of the client device 104 detects a userinteraction selecting a selectable element (e.g., a confirm purchasebutton) to initiate and/or complete the purchase of the product. Theclient device 104 detecting a user interaction causing a purchase of theproduct is described in greater detail below in regard to FIGS. 3D and3E.

As shown in FIG. 2B, upon the client device 104 detecting the userinteraction causing a purchase of the product, the merchant system 102receives an indication of the purchase, as shown in act 230. Forexample, upon detecting the user interaction causing a purchase of theproduct, the client device 104 and/or the client application 112 canprovide an indication of the purchase to the merchant system 102. In oneor more embodiments, the merchant system 102 can receive the indicationof the purchase through the network 108.

In response to receiving the indication of the purchase through theprovisional account, as illustrated in FIG. 2B, the merchant system 102processes a payment for the product, as shown in act 231. For example,the merchant system 102 can process the payment for the productaccording to the payment information provided to the merchant system inact 222 of FIG. 2B. In some embodiments, the merchant system 102 canprocess the payment through a payment gateway (e.g., software andservers for transmitting transaction information to acquiring banks andresponses from issuing banks (such as whether a transaction is approvedor declined)). For example, the payment gateway can implement PaymentCard Industry Data Security Standard (PCI-DSS or PCI).

Upon processing the payment for the product, the merchant system 102 canassociate the purchase with the provisional account. For example, themerchant system 102 can create a data package indicating the purchaseproduct and can associate the data package with the provisional accountsuch that the provisional account indicates that the user purchased theproduct and has rights to the purchased product.

Furthermore, upon processing the payment for the product, as illustratedin FIG. 2B, the merchant system 102 disables (e.g., blocks) use of thepurchased product by the user, as shown in act 232. For example, themerchant system 102 blocks operation of the product (e.g. operation of asoftware product) in connection with the provisional account and blocks(e.g., prevents) any downloads of the product (e.g., downloads of thesoftware product). In particular, the merchant system 102 can block useof the product in connection with the provisional account. For instance,as mentioned above, purchased products may not be usable via provisionalaccounts of the merchant system 102. In some embodiments, the merchantsystem 102 blocks use of the product merely via the assigned provisionalstate of the provisional account of the user (due to the provisionalidentifier) within the database 114 of the identification system 106. Aswill be discussed in greater detail below, the merchant system can blockuse of the purchase product until the user completes a claiming action(e.g., creating or setting a user credential/password).

In some embodiments, in response to processing the payment for theproduct (e.g., completing the purchase of the product), the merchantsystem 102 can issue a limited use access token. For example, themerchant system 102 can issue a limited use access token specific to acurrent web browsing session (e.g., the web browsing session withinwhich the product was purchased). The limited use access token canprovide access to some services of the merchant system 102. For example,the limited use access token can provide access to purchase details,product details, etc. However, the limited use access token does notprovide access to the purchased product (e.g., use of the purchaseproduct).

Additionally, in response to processing the payment for the product(e.g., completing the purchase of the product), as illustrated in FIG.2B, the merchant system 102 generates a communication to the userrequesting that the user create a user credential (e.g., a password), asshown in act 234. For example, the merchant system 102 can generate acommunication to the user requesting that the user complete a creationof a permanent account with the merchant system 102. In someembodiments, the merchant system 102 can generate a communication to theuser requesting that the user verify an email address (e.g., a useridentifier) and create a password. In some embodiments, the merchantsystem 102 can generate a preset communication stored on the database114. In additional embodiments, the merchant system 102 can generate thecommunication via a natural language generator system.

In some embodiments, the communication can include an email to the user(e.g., addressed to the user identifier) having a link within the emailfor verifying the email address and for creating (e.g., choosing) a usercredential (e.g., password). In such embodiments, the email can includea message requesting that the user verify the email address and tocreate a user credential. For example, the email may include a messagesuch as, “Click below to confirm your account and create a password.”Generating a communication including an email is described in furtherdetail below in regard to FIG. 3F.

In additional embodiments, the communication can include a notificationwithin the client application 112 having a link for creating a usercredential. For example, the communication can include notification(e.g., option) on a purchase confirmation web page. In such embodiments,the notification can include a message requesting that the user create auser credential (e.g., password). For example, the notification caninclude a message such as “Set your password to sign in to get started”and a selectable link to set the password. As noted above, in someembodiments, the merchant system 102 can adjust a preset communication(e.g., a preset notification) stored on the database 114. For example,the merchant system 102 can address the preset communication to the userbased on the received user identifier and/or payment information. Inadditional embodiments, the merchant system 102 can generate thecommunication via a natural language generator system based on thereceived user identifier and/or payment information. Generating acommunication including a notification within a confirmation page isdescribed in further detail below in regard to FIG. 3E.

Upon generating the communication to the user requesting that the usercreate a user credential, the merchant system 102 provides a completedpurchase confirmation to the client device 104, as shown in act 236 ofFIG. 2C. For instance, the merchant system 102 can provide a completedpurchase webpage to the client device 104 and/or client application 112for display to the user 110. In some embodiments, the completed purchasewebpage includes an indication of the of the communication generated inact 234 of FIG. 2B.

Additionally, upon generating the communication to the user requestingthat the user create a user credential, the merchant system 102 providesthe generated communication to the client device 104, as shown in act238 of FIG. 2C. For instance, the merchant system 102 can provide thegenerated communication to the client device 104 and/or clientapplication 112 for display to the user 110. As noted above, in someembodiments the generated communication can include an email. In suchembodiments, the merchant system 102 can send to the email to an emailaddress (e.g., the user identifier) associated with the user. As alsomentioned briefly above, in some embodiments, the generatedcommunication can include a notification, and in such embodiments, themerchant system 102 can provide the notification within the completedpurchase webpage.

Referring still to FIG. 2C, in some embodiments, after disabling (e.g.,blocking) use of the product, the merchant system 102 can receive arequest to use the product, as shown in act 240 of FIG. 2C. For example,the merchant system 102 can receive a request to download the product(e.g., download a software product) via the provisional account. Forinstance, a user may select a download option after purchasing theproduct (e.g., within the same web browsing session). As anothernon-limiting example, the merchant system 102 can receive a request tooperate the product (e.g., run a software product) via the provisionalaccount. In particular, a user may select an option to operate a webbased portion of the product. In another non-limiting example, themerchant system 102 can receive a request to login with the provisionalaccount. Specifically, a user may attempt to login to the merchantsystem 102 after purchasing the product.

In response to receiving the request to use the product, the merchantsystem 102 determines whether a user identifier associated with therequest is associated with a preexisting account of the merchant system,as shown in act 241 of FIG. 2C. For example, as discussed above, themerchant system 102 can query the identification system 106 (e.g., querythe identification system 106 via the API gateway) to determine whetherthe user identifier is associated with a preexisting provisional accountor a permanent account of the merchant system 102. In some embodiments,as mentioned above, the identification system 106 can query the database114 to determine whether the user identifier associated with the requestis associated with a preexisting account of the merchant system 102. Forinstance, the merchant system 102 can query the identification system106, which, in turn, can compare the received user identifier with useridentifiers associated with preexisting accounts of the merchant system102 within the database 114 and can communicate with the merchant system102 as to whether the user identifier is associated with a preexistingaccount.

Also, as described briefly above, if the merchant system 102 determinesthat the user identifier is associated with a preexisting permanentaccount, the merchant system 102 can request (e.g., require) that theuser input a user credential (e.g., ask for a password) prior toproviding access to the purchased product. For instance, the merchantsystem 102 can require the user to login into the merchant system 102via the user identifier and user credential.

If, on the other hand, the merchant system 102 determines that the useridentifier is associated with a preexisting provisional account, as isdiscussed in greater detail below in regard to FIG. 4, the merchantsystem 102 can prevent use of the purchased product, as shown in act 242of FIG. 2C. For example, the merchant system 102 can deny (e.g., block)use of the purchase product. For instance, in response to a request todownload the product, the merchant system 102 can prevent the productfrom being downloaded. Furthermore, as will be described in greaterdetail below, the merchant system 102 can require the user to create auser credential prior to enabling use of the purchased product.

For example, in response to the merchant system 102 determining that theuser identifier is associated with a preexisting provisional account,the merchant system can provide a request to the user to create a usercredential, as shown in act 244 of FIG. 2C. For instance, the merchantsystem 102 can provide a communication to the user (e.g., a pop-upmessage in response to a download request) again instructing the user tocomplete a creation of a permanent account (e.g., create a usercredential) with the merchant system 102. For example, the merchantsystem 102 can provide instructions within the client application GUIand/or the merchant system GUI on how to create a user credential (e.g.,set a password). Specifically, the instructions can include any of theinstructions described above in regard to acts 236 and 238 of FIGS. 2Band 2C.

Upon being provided with the generated communication of act 238 and/orthe request of act 244 of FIG. 2C, the client device 104 detects a userinteraction to create the user credential. For example, the clientapplication 112 of the client device 104 detects a user interaction tocreate a user credential within the client application 112 (e.g., theclient application GUI). In some embodiments, the client device 104 candetect a user interaction selecting a link within the sent email and auser interaction inputting a chosen user credential. In additionalembodiments, the client device 104 can detect a user interactioninputting a chosen user credential during an attempted login of the userinto the merchant system 102. Detecting a user interaction to create auser credential is described in greater detail below in regard to FIGS.3E-3G.

As shown in FIG. 2C, upon the client device 104 detecting the userinteraction to create a user credential, the merchant system 102receives an indication of the user interaction to create the usercredential, as shown in act 242. For example, upon detecting the userinteraction to create the user credential, the client device 104 and/orthe client application 112 can provide an indication of the userinteraction to create the user credential to the merchant system 102.For instance, the client device 104 and/or the client application 112can provide a data package including the chosen (e.g., inputted) usercredential. In one or more embodiments, the merchant system 102 canreceive the indication of the user interaction to create the usercredential through the network 108.

Although the user interaction to create the user credential is describedherein as being detected by and received from the same client device 104through which the product was purchased, the disclosure is not solimited. Rather, in some instances, the merchant system 102 can enable apurchase of the product through a first client device (e.g., a desktopcomputer), and the merchant system 102 can receive the indication of theuser interaction to create the user credential from a second clientdevice (e.g., a mobile device). In other words, the product can bepurchased via a first client device, and the user credential can becreated via a second client device. The individual actions of purchasingthe product (e.g., creating a provisional account associated with theuser identifier) and creating a permanent account associated with thepurchase and the user identifier are client device and/or browsingsession agnostic. As a result, the merchant system 102 is advantageousover conventional purchasing systems (e.g., guest checkouts), which aretypically browsing session specific, and as a result, are client devicespecific.

In response to receiving the indication of the user interaction tocreate the user credential, the merchant system 102 creates the usercredential, as shown in act 248 of FIG. 2C. For example, upon receivingthe indication of the user interaction to create the user credential,the merchant system 102 can set the user credential (e.g., thepassword). For instance, the merchant system 102 can associate the usercredential with the user identifier. In particular, the merchant system102 can create a data package including the user credential and canassociate it with the user identifier within the database 114 of theidentification system 106.

Furthermore, in response to receiving the indication of the userinteraction to create the user credential, the merchant system convertsthe provisional account associated with the user identifier to apermanent account, as shown in act 250 of FIG. 2D. For instance, themerchant system 102 can create a permanent account associated with theuser identifier and the user credential. In one or more embodiments, themerchant system 102 can communicate with the identification system 106,and the identification system 106 can convert the provisional account toa permanent account within the database 114 of the merchant system 102.In some embodiments, the merchant system 102 can create the permanentaccount by creating a data package establishing (e.g., defining) apermanent relationship between the user and the merchant system 102 andassociating the user identifier and user credential with the datapackage within the database 114 of the identification system 106.

As noted above, the merchant system 102 creates the permanent accountsuch that the permanent account is capable of using a purchased productof the merchant system 102. For instance, in some embodiments, whencreating the provisional account, the merchant system 102 can associatea permanent identifier with the permanent account within the database114 of the identification system 106. In other words, the merchantsystem 102 can tag the permanent account with the permanent identifierwithin the database 114 of the identification system 106. Furthermore,based on the permanent identifier of the permanent account, the merchantsystem 102 may allow a user credential to be entered during a loginattempt and, as is discussed in greater detail below, upon a validlogin, may allow use of the product through the permanent account.

In some instances, the merchant system 102 creates the permanent accountby removing the provisional identifier from the provisional account andreplacing the provisional identifier with a permanent identifier withinthe database 114 of the identification system 106. For example, themerchant system 102 creates a data package including the permanentidentifier and associates the data package with the account (now thepermanent account). In alternative embodiments, the merchant system 102creates the permanent account by creating an entirely new permanentaccount and associating the user identifier and user credential with thenew permanent account. Furthermore, in such embodiments, the merchantsystem 102 removes (e.g., deletes) the provisional account from thedatabase 114 of the identification system 106.

Upon creating the permanent account, the merchant system 102 enables useof a purchased product through the permanent account, as shown in act252 of FIG. 2D. For example, the merchant system 102 enables operationof the product (e.g., operation of a software product) and/or a downloadof the product via the permanent account. For instance, the permanentaccount can grant access to (e.g., use of) purchased products.

For example, after the merchant system 102 creates the permanent accountand enables use of the purchased product through the permanent account,the merchant system 102 can receive a request to utilize the product, asshown in act 254 of FIG. 2D. For example, the merchant system 102 canreceive a request to download the product (e.g., download a softwareproduct) via the permanent account. For instance, a user may select adownload option after purchasing the product and creating a usercredential. As another non-limiting example, the merchant system 102 canreceive a request to operate the product (e.g., run a software product)via the permanent account. In particular, a user may select an option tooperate a web based portion of the product. As another non-limitingexample, the merchant system 102 can receive a request to login to themerchant system 102 with the permanent account. Specifically, a user mayattempt to login to the merchant system 102 after purchasing the productand creating a user credential.

In response to receiving the request to utilize the product, themerchant system 102 determines whether a user identifier associated withthe request is associated with a preexisting account of the merchantsystem, as shown in act 255 of FIG. 2C. For example, the merchant systemcan perform any of the actions described above in regard to acts 214 and241 of FIGS. 2A and 2C. If, on one hand, the merchant system 102determines that the user identifier is associated with a preexistingprovisional account, the merchant system 102 can perform any of theactions described above in regard to determining that a user identifieris associated with a preexisting provisional account.

If, on the other hand, the merchant system 102 determines that the useridentifier is associated with a preexisting permanent account, as isdiscussed in greater detail below in regard to FIG. 4, the merchantsystem 102 can request (e.g., require) that the user input a previouslycreated user credential (e.g., ask for a password) prior to providingaccess to the purchased product.

Furthermore, upon determining that the user identifier is associatedwith a preexisting permanent account and requiring the user to login tothe merchant system 102 (e.g., to provide the user identifier and usercredential combination), the merchant system 102 can permit (e.g.,allow) use of the product, as shown in act 256 of FIG. 2C. For example,the merchant system 102 allows operation of the product (e.g., operationof a software product) and/or a download of the product (a download of asoftware product).

Referring FIGS. 2A-2D together, in some embodiments, accounts of themerchant system 102 can be assigned one of at least three statuses. Forexample, the accounts of the merchant system 102 can be assigned aprovisional pre-purchase status, a provisional post-purchase status, anda permanent status. In particular, the merchant system 102 assigns aprovisional pre-purchase status to an account where the user hasprovided a username but has not completed a purchase of a product.Furthermore, the merchant system 102 assigns a provisional post-purchasestatus to an account where the user has provided a username and hascompleted a purchase of a product. Moreover, the merchant system 102assigns a permanent status to an account where the user has provided ausername and a user credential. Additionally, as noted above, a statusof the account can be assigned within the database 114 of theidentification system 106.

FIGS. 3A-3G illustrate a collection of user interfaces includingfeatures of the merchant system 102 according to one or more embodimentsof the present disclosure. As will be described in more detail below,the components of the merchant system 102 as described in regard toFIGS. 1-2D can provide, along and/or in combination with the othercomponents, one or more graphical user interfaces (“GUIs”). Inparticular, the components can allow a user to interact with acollection of display elements for a variety of purposes. For instance,FIG. 3A-3G and the description that follows illustrate various exampleembodiments of the user interfaces and features that are in accordancewith one or more embodiments of the present disclosure.

For example, FIG. 3A illustrates a user device 302 that may implementone or more of the components or features of the merchant system. Forpurposes of the present disclosure, the user device 302 may be a clientdevice (e.g., client device 104). As shown in FIG. 3A, in someembodiments, the user device 302 is a handheld device, such as a tabletdevice. As used herein, the term “handheld device” refers to a devicesized and configured to be held/operated in one or more hands of a user.In additional or alternative examples, however, any other suitablecomputing device, such as, but not limited to, a mobile phone device,larger wireless device, laptop or desktop computer, a personal digitalassistant device, and/or any other suitable computing device can performone or more of the processes and/or operations described herein.

The user device 302 includes a touch screen display 304 that can displayuser interfaces. Furthermore, the user device 302 receives and/ordetects user input via the touch screen display 304. As used herein, a“touch screen display” refers to the display of a touch screen device.In one or more embodiments, a touch screen device may be the user device302 with at least one surface upon which a user may perform touchgestures (e.g., a laptop, a tablet computer, a personal digitalassistant, a media player, a mobile phone, etc.). Additionally, oralternatively, the user device 302 may include any other suitable inputdevice, such as a touch pad or those described below with reference toFIG. 12.

As shown in FIG. 3A, the touch screen display 304 of the user device 302displays a merchant system graphical user interface (“GUI”) 310 providedby the merchant system 102, which, in some embodiments, can beaccessible by the user device 302. For example, as described above inregard to FIG. 1, the user device 302 (e.g., client device 104) canaccess the merchant system 102 via a network (e.g., network 108). Asillustrated in FIG. 3A, the merchant system GUI 310 can display a useridentifier input GUI 311 during a purchase process of the user. Forexample, the merchant system GUI 310 can display the user identifierinput GUI 311 in response to a user electing to purchase a product.

As shown in FIG. 3A, the user identifier input GUI 311 can include aproduct identifying element 306 that indicates the product that the useris electing to purchase. For example, the product identifying element306 can identify the product and can indicate a purchasing price.Furthermore, the user identifier input GUI 311 can also include a useridentifier input field 308 where the merchant system 102 can receive auser identifier from the user (e.g., where a user can provide the useridentifier). As shown in FIG. 3B, a user can enter a username into theuser identifier input field 308 and press the continue element. Inresponse to which, the client device can send the entered useridentifier to the merchant system 102 as described above in relation toFIG. 2A.

Additionally, as shown in FIGS. 3C and 3D, the merchant system GUI 310can display a payment information input GUI 313 during a purchaseprocess. For example, the merchant system GUI 310 can display thepayment information input GUI 313 in response to receiving the useridentifier from the user as shown in FIG. 3B. As illustrated in FIGS. 3Cand 3D, the payment information input GUI 313 can include a plurality ofpayment information fields 312 where the merchant system 102 can receivethe payment information from the user. Furthermore, the paymentinformation input GUI 313 can include the product identifying element306 and a user selectable element 314 for placing (e.g., completing) thepurchase. After entering the payment information as shown in FIG. 3C,the user can select the user selectable element 314. In response, theclient device 302 can send the payment information 222 to the merchantsystem 106.

Furthermore, as shown in FIG. 3E, the merchant system GUI 310 candisplay a purchase confirmation GUI 316. For example, the merchantsystem GUI 310 can display the purchase confirmation GUI 316 in responsethe user completing a purchase with the merchant. For instance, themerchant system GUI 310 can display the purchase confirmation GUI 316during act 236 of FIG. 2B. As illustrated in FIG. 3E, the purchaseconfirmation GUI 316 can include a confirmation message that thepurchase of the product has been completed. Furthermore, the purchaseconfirmation GUI 316 can include a message indicating that thecommunication described above in regard to act 234 of FIG. 2B has beensent to the user. Moreover, in some embodiments, the purchaseconfirmation GUI 316 can include a user credential creation element 318.For example, the purchase confirmation GUI 316 can include a link forcreating a user credential.

FIG. 3F illustrates an example communication 324 (e.g., email) that themerchant system 102 can provide to the user. For example, the merchantsystem 102 can provide the communication 324 during act 238 of FIG. 2C.As shown, the communication 324 can include an account confirmation link326 through which a user can verify an email address and create a usercredential. Furthermore, the communication 324 can include any of thecommunications described above in regard to act 234 of FIG. 2B. One willappreciate that the merchant system 102 provides the purchaseconfirmation GUI 316 with link for creating a user credential and/or thecommunication 324 with the account confirmation link 324 only after theuser completes the purchase of the product.

In response to a user selection of the link for creating a usercredential, the merchant system GUI 310 can display a user credentialcreation GUI 327. For example, the merchant system GUI 310 can displaythe user credential creation GUI 327 in response the user selecting theaccount confirmation link 326 from the communication 324 and/or usercredential creation element 318 of the purchase confirmation GUI 316. Asshown, the user credential creation GUI 327 can include a usercredential input field 328 where the user can input and/or create a usercredential. In response to the entering the password in the usercredential input field 328, the client device 302 can send the usercredential to the merchant system 102 as described above. The merchantsystem 248 can then convert the provisional account into a permanentaccount as described above.

FIG. 4 illustrates a diagram of an algorithm for managing states of useraccounts in connection with providing access to software over a network.In particular, FIG. 4 includes an algorithm for a step for 400preventing use of the software as a service product associated with theprovisional account. Furthermore, the step for 400 can include any ofthe actions described below in regard to boxes 402 and 406-420. Asillustrated in box 402 of FIG. 4, the algorithm includes receiving auser identifier. For example, the merchant system can receive a useridentifier from a client device (e.g., client device 104) In someembodiments, the merchant system 102 can receive a user identifierduring a purchase process (e.g., in response to a request for the useridentifier during a purchase process). In additional embodiments, themerchant system 102 can receive a user identifier during a login attempt(e.g., an attempt to login to the merchant system 102) by a user. Forexample, the algorithm can include any of the actions describe above inregard to acts 212 and 240 of FIGS. 2B and 2C.

Additionally, the algorithm includes determining whether the receiveduser identifier is associated with a permanent account of the merchantsystem 102, as shown in box 404 of FIG. 4. For example, the merchantsystem 102 can query the identification system 106 and the database 114to determine whether the user credential is associated with a permanentaccount of the merchant system 102. For example, in some embodiments,the merchant system 102 can communicate with the identification system106, which can, in turn, query the database 114 to determine whether theuser credential is associated with a permanent account. Furthermore, thealgorithm can include any of the actions described above in regard toacts 214, 241, 255 of FIGS. 2B-2D.

If the merchant system 102 determines that the user identifier isassociated with a permanent account of the merchant system 102, thealgorithm includes requesting the user credential, as shown in box 422of FIG. 4. For example, the merchant system can request the usercredential within the client application 112 (e.g., a web browser and/orapplication specific to the merchant system 102 (e.g., a shoppingapplication)) of the client device 104. In other words, the merchantsystem 102 can ask for a password associated with the received useridentifier. In some embodiments, the merchant system 102 can request theuser credential via a user credential input field of the merchant systemGUI 310.

Furthermore, upon receiving the user credential (e.g., a combination ofthe user identifier and the user credential), the algorithm includesenabling the user to login to the merchant system 102 and enabling useof products of the merchant system 102, as shown in box 424 of FIG. 4.In particular, the merchant system 102 allows a user to use purchasedproducts of the merchant system 102 via the permanent account. In someembodiments, the merchant system 102 can enable a download of thepurchased products. In additional embodiments, the merchant system 102can enable operation of the purchased products.

If, on the other hand, the merchant system 102 determines that the useridentifier is not associated with a permanent account of the merchantsystem 102, the algorithm includes determining whether the received useridentifier is associated with a provisional account of the merchantsystem 102, as shown in box 406 of FIG. 4. For example, the merchantsystem 102 can query the identification system 106 and the database 114to determine whether the user credential is associated with aprovisional account of the merchant system 102. For example, in someembodiments, the merchant system 102 can communicate with (e.g., call)the identification system 106, which, in turn, can (e.g., query thedatabase 114 to) determine whether the user credential is associatedwith a provisional account. Furthermore, the algorithm can include anyof the actions described above in regard to acts 214, 241, 255 of FIGS.2B-2D.

If the merchant system 102 determines that the user identifier isassociated with a provisional account of the merchant system 102, thealgorithm includes providing instructions to the user on how to create auser credential, as show in box 420 of FIG. 4. For example, the merchantsystem 102 can provide instructions within the client application GUIand/or the merchant system GUI on how to create a user credential (e.g.,set a password). In some embodiments, the instructions can direct theuser to create a user credential through a link a previously sent email.In other embodiments, the instructions can direct the user to create auser credential within the client application GUI and/or the merchantsystem GUI (e.g., within the current web browsing session). In yet otherembodiments, the instructions can provide an option to resend thepreviously sent email including a link to create a user credential.

If the merchant system 102 determines that the user identifier is notassociated with a provisional account, the algorithm includes creating aprovisional account associated with the user identifier, as shown in box408 of FIG. 4. For example, as mentioned above in regard to act 216 ofFIG. 2A, the merchant system 102 can communicate with the identificationsystem 106, and the identification system 106 can create the provisionalaccount within the database 114 of the merchant system 102. In someembodiments, the merchant system 102 can create the provisional accountby creating a data package establishing (e.g., defining) a provisionalrelationship between the user and the merchant system 102 andassociating the user identifier with the data package within thedatabase 114 of the identification system 106. For example, theprovisional account can allow a user to purchase a product while denyinguse of the product.

As noted above, the merchant system creates a provisional account thatenables (e.g., permits) a user to purchase products from the merchantsystem but does not allow the user to use the purchased products. Forinstance, in some embodiments, when creating the provisional account,the merchant system 102 can associate a provisional identifier with theprovisional account within the database 114 of the identification system106. In other words, the merchant system 102 can tag (e.g., mark orlabel) the provisional account with the provisional identifier (e.g.,tag) within the database 114 of the identification system 106.Furthermore, based on the provisional identifier of the provisionalaccount, the merchant system 102 may not allow a user credential to beentered during a login attempt and may not allow use of the productthrough the provisional account. As will be discussed in greater detailbelow, the provisional account requires a user to perform additionalactions (e.g., claiming actions) to create a permanent account and tocreate a user credential in order to use the purchased product.

In some embodiments, creating the provisional account can furtherinclude reserving the received user identifier for the provisionalaccount within the database 114 of the identification system 106.Furthermore, the merchant system 102 can create a data packageassociated with the user identifier that defines the access of theprovisional account of the user and can store the data package withinthe database 114 of the identification system 106. Moreover, thealgorithm can include any of the actions described above in regard toacts 216 and 224.

Upon creating the provisional account, the algorithm includes enabling apurchase of products of the merchant system through the provisionalaccount, as shown in box 410 of FIG. 4. For example, the merchant system102 can enable purchase of products of the merchant system 102 throughany of the manners described above in regard to act 226 of FIG. 2B.

Furthermore, in response to a completed purchase of a product of themerchant system, the algorithm includes preventing (e.g., blocking) useof the purchased product through the provisional account, as shown inbox 412 of FIG. 4. For example, the merchant system 102 blocks operationof the product (e.g. operation of a software product) within theprovisional account and blocks (e.g., prevents) a download of theproduct (e.g. download of the software product). In particular, themerchant system 102 can block use of the product within the provisionalaccount. In particular, the merchant system 102 can block use of theproduct merely via the assigned provisional state of the provisionalaccount of the user (due to the provisional identifier). As will bediscussed in greater detail below, the merchant system can block use ofthe purchase product until the user completes a claiming action (e.g.,creating a user credential (e.g., password)). Furthermore, the algorithmcan include any of the actions described above in regard to acts 232 and242.

Moreover, upon the merchant system preventing use of the product, thealgorithm includes providing a communication requesting that the usercreate a user credential, as shown in box 414 of FIG. 4. For example,the merchant system 102 can provide a communication to the userrequesting that the user complete a creation of a permanent account withthe merchant system 102 (e.g., complete a claiming action). In someembodiments, the merchant system 102 can provide a communication to theuser requesting that the user verify an email address and create apassword. For example, the communication can include an email to theuser having a link within the email for verifying the email address andfor creating (e.g., choosing) a user credential (e.g., password).

Furthermore, as noted above, the communication can include anotification within the client application 112 of the client device 104having a link for creating a user credential. For example, thecommunication can include notification (e.g., option) on a purchaseconfirmation web page. In such embodiments, the notification can includea message requesting that the user create a user credential (e.g.,password). For example, the algorithm can include any of the actionsdescribed above in regard to acts 234, 236, and 244 of FIGS. 2B and 2C.

Upon the creation of a user credential, for example, a creation of auser credential through any of the actions described above in regard toacts 246 and 248 of FIG. 2C, the algorithm can include converting theprovisional account into a permanent account, as shown in box 416 ofFIG. 4. For example, the merchant system 102 can create a permanentaccount associated with the user identifier and the user credential. Insome embodiments, the merchant system 102 can create the permanentaccount by associating a permanent identifier with the permanent accountwithin the database 114 of the identification system 106. In otherwords, the merchant system 102 can tag the permanent account with thepermanent identifier within the database 114 of the identificationsystem 106.

In some embodiments, the merchant system 102 creates the permanentaccount by removing the provisional identifier from the provisionalaccount and replacing the provisional identifier with a permanentidentifier within the database 114 of the identification system 106. Forexample, the merchant system 102 creates a data package including thepermanent identifier and associates the data package with the account(now the permanent account). In alternative embodiments, the merchantsystem 102 creates the permanent account by creating an entirely newpermanent account and associating the user identifier and usercredential with the new permanent account. Furthermore, as mentionedabove, in such embodiments, the merchant system 102 removes (e.g.,deletes) the provisional account from the database 114 of theidentification system 106.

Upon creating the permanent account, the algorithm includes enabling useof a purchased product through the permanent account, as shown in act252 of FIG. 2D. For example, in response to receiving a valid useridentifier and user credential (e.g., logging into a valid permanentaccount) the merchant system 102 enables operation of the product (e.g.,operation of a software product) and/or a download of the product viathe permanent account.

FIGS. 1-4, the corresponding text, and the examples, provide a number ofdifferent systems and devices for managing states of user accounts inconnection with providing access to software over a network. In additionto the foregoing, embodiments can be described in terms of flowchartscomprising acts and steps in a method for accomplishing a particularresult. For example, FIGS. 5 and 6 illustrate flowcharts of exemplarymethods in accordance with one or more embodiments.

FIG. 5 illustrates a flowchart of an example method 500 of managingstates of user accounts in connection with providing access to softwareover a network. The method 500 can be implemented by the merchant system102 described above. In some embodiments, the method 500 involves an act520 of receiving a user identifier. Specifically, the act 520 caninclude receiving the user identifier from a user via a client device inconnection with a request to purchase a software as a service product.In some instances, the act 520 can include receiving the user identifierfrom a first web browsing session. Moreover, the act 520 can include anyof the actions described above in regard act 212 to FIG. 2A.

Additionally, the method 500 includes an act 530 of enabling a purchaseof a software as a service product through a provisional account. Themethod 500 can include associating the purchase of the software as aservice product and the user identifier with a provisional account. Inparticular, the act 530 may include enabling a purchase of the softwareas a service product without requiring creation of a full user account.For example, act 530 can involve enabling purchase of the softwareproduct without requiring a password.

In some instances, act 530 can further include receiving a request,associated with the user identifier, to download the software as aservice product, determining that the user identifier is associated withthe permanent account, and enabling a download of the software as aservice product. Additionally, the act 530 can include any of theactions described above in regard to acts 214-226 of FIGS. 2A and 2B.

Moreover, the method 500 includes an act 540 of preventing use of thesoftware as a service product. For example, the act 540 may includepreventing use of the software as a service product through theprovisional account. Furthermore, the act 540 can include receiving arequest, associated with the user identifier, to download the softwareas a service product, determining that the user identifier is associatedwith the provisional account, blocking a download of the software as aservice product, and requesting a user credential to enable access tothe purchased software as a service product. Additionally, the act 540may include any of the actions described above in regard to acts 232 and242 of FIGS. 2B and 2C.

Furthermore, the method 500 includes an act 550 of requesting a creationof a user credential. For instance, the act 550 can include, in responseto a completed purchase of the software as a service product, requestinga creation of a user credential. In some embodiments, requesting acreation of a user credential includes sending an email to the userrequesting a creation of a user credential. In additional embodiments,requesting a creation of a user credential includes providing a requestwithin a confirmation webpage of a completed purchase of the software asa service product. Additionally, the act 550 may include any of theactions described above in regard to acts 234 and 238 of FIGS. 2B and2C.

Also, the method 500 includes an act 560 of receiving the usercredential. For instance, the act 560 can include receiving the usercredential from the user via the client device. Furthermore, in someembodiments, the user credential is received from a second, differentclient device. Moreover, the act 560 can include any of the actionsdescribed above in regard to act 246 of FIG. 2C.

Additionally, the method 500 includes an act 570 of converting aprovisional account into a permanent account. For instance, the act 570can include, in response to receiving the user credential, convertingthe provisional account into a permanent account associated with theuser identifier and user credential. Furthermore, ins some embodiments,the act 570 can include removing a provisional identifier from theprovisional account within the database of the identification system,associating a permanent identifier with the provisional account withinthe database of the identification system to create the permanentaccount, and associating the user credential with the permanent account.In alternative embodiments, the act 570 can include removing theprovisional account and an associated provisional identifier from thedatabase of the identification system, creating a new permanent accountwithin the database of the identification system, associating apermanent identifier with the permanent account within the database ofthe identification system, and associating the user identifier and theuser credential with the permanent account within the database of theidentification system. Moreover, the act 570 can include any of theactions described above in regard to act 250 of FIG. 2D.

Additionally, the method 500 includes an act 580 of enabling use of thesoftware as a service product through the permanent account. Forinstance, the act 570 can include, receiving a request, associated withthe user identifier, to download the software as a service product,determining that the user identifier is associated with the permanentaccount, and enabling a download of the software as a service product.In some embodiments, the act 580 can include comprises enabling adownload of the software as a service product. In additionalembodiments, the act 580 can include enabling operation of the softwareas a service product. Moreover, the act 580 can include any of theactions described above in regard to act 252 of FIG. 2D.

FIG. 6 illustrates a flowchart of an example method 600 of managingstates of user accounts in connection with providing access to softwareover a network. The method 600 can be implemented by the merchant system102 described above. In some embodiments, the method 600 involves an act615 of receiving the user identifier. Specifically, the act 615 caninclude receiving the user identifier from a user via a client device inconnection with a request to purchase a software as a service product.In some instances, the act 615 can include receiving the user identifierfrom a first web browsing session. Moreover, the act 615 can include anyof the actions described above in regard act 212 to FIG. 2A.

Additionally, the method 600 includes an act 620 determining whether theuser identifier is associated with a preexisting account. For example,the act 620 can include determining whether the user identifier isassociated with a preexisting account of a merchant system related tothe software as a service product by querying an identification system.For instance, the act 620 can include querying an identification systemand comparing the user identifier with preexisting accounts.

Additionally, the method 600 includes an act 625 of creating aprovisional account associated with the user identifier. In particular,the act 625 may include, upon determining that the user identifier isnot associated with a preexisting account, creating a provisionalaccount associated with the user identifier. In some instances, the act625 can further include creating the provisional account such that theprovisional account enables the user to download at least onedownloadable image from the database of downloadable images.Additionally, the act 625 can include any of the actions described abovein regard to act 216 of FIGS. 2A and 2B. Additionally, the method 600includes an act 630 of enabling a purchase of the software as a serviceproduct through a provisional account. In particular, the act 630 mayinclude facilitating a purchase of the software as a service productthrough the provisional account without a creation of a full usercredential. In some instances, act 630 can further include receiving arequest, associated with the user identifier, to download the softwareas a service product, determining that the user identifier is associatedwith the permanent account, and enabling a download of the software as aservice product. Additionally, the act 630 can include any of theactions described above in regard to acts 214-226 of FIGS. 2A and 2B.

Moreover, the method 600 includes an act 635 of preventing use of thesoftware as a service product. For example, the act 635 may includepreventing use of the software as a service product through theprovisional account by blocking one or more of a download of thesoftware as a service product and operation of the software as a serviceproduct through the provisional account. For example, the act 635 caninclude receiving a request, associated with the user identifier, todownload the software as a service product, determining that the useridentifier is associated with the provisional account, and blocking adownload of the software as a service product. Additionally, the act 635may include any of the actions described above in regard to acts 232 and242 of FIGS. 2B and 2C.

Furthermore, the method 600 includes an act 640 of requesting a usercredential. For instance, the act 640 can include requesting a usercredential to enable access to the purchased software as a serviceproduct. In some embodiments, requesting a user credential includessending an email to the user requesting a creation of a user credential.In additional embodiments, requesting a user credential includesproviding a request within a confirmation webpage of a completedpurchase of the software as a service product. Additionally, the act 640may include any of the actions described above in regard to acts 234 and238 of FIGS. 2B and 2C.

Also, the method 600 includes an act 645 of receiving the usercredential. For instance, the act 560 can include receiving the usercredential from the user via the client device. Furthermore, in someembodiments, the user credential is received from a second, differentclient device. Moreover, the act 645 can include any of the actionsdescribed above in regard to act 246 of FIG. 2C.

Additionally, the method 600 includes an act 650 of converting aprovisional account into a permanent account. For instance, the act 650can include, in response to receiving the user credential, convertingthe provisional account into a permanent account associated with theuser identifier, the user credential, and the purchase of the softwareas a service product. Furthermore, in some embodiments, the act 650 caninclude removing a provisional identifier from the provisional accountwithin the database of the identification system, associating apermanent identifier with the provisional account within the database ofthe identification system to create the permanent account, andassociating the user credential with the permanent account. Inalternative embodiments, the act 650 can include removing theprovisional account and an associated provisional identifier from thedatabase of the identification system, creating a new permanent accountwithin the database of the identification system, associating apermanent identifier with the permanent account within the database ofthe identification system, and associating the user identifier and theuser credential with the permanent account within the database of theidentification system. Moreover, the act 650 can include any of theactions described above in regard to act 250 of FIG. 2D.

Additionally, the method 600 includes an act 655 of enabling use of thesoftware as a service product through the permanent account. Forinstance, the act 655 can include, enabling use of the software as aservice product through the permanent account by permitting one or moreof a download of the software as a service product and operation of thesoftware as a service product through the permanent account. Moreover,the act 655 can include any of the actions described above in regard toact 252 of FIG. 2D.

Embodiments of the present disclosure may comprise or utilize a specialpurpose or general-purpose computer including computer hardware, suchas, for example, one or more processors and system memory, as discussedin greater detail below. Embodiments within the scope of the presentdisclosure also include physical and other computer-readable media forcarrying or storing computer-executable instructions and/or datastructures. In particular, one or more of the processes described hereinmay be implemented at least in part as instructions embodied in anon-transitory computer-readable medium and executable by one or morecomputing devices (e.g., any of the media content access devicesdescribed herein). In general, a processor (e.g., a microprocessor)receives instructions, from a non-transitory computer-readable medium,(e.g., a memory, etc.), and executes those instructions, therebyperforming one or more processes, including one or more of the processesdescribed herein.

Computer-readable media can be any available media that can be accessedby a general purpose or special purpose computer system.Computer-readable media that store computer-executable instructions arenon-transitory computer-readable storage media (devices).Computer-readable media that carry computer-executable instructions aretransmission media. Thus, by way of example, and not limitation,embodiments of the disclosure can comprise at least two distinctlydifferent kinds of computer-readable media: non-transitorycomputer-readable storage media (devices) and transmission media.

Non-transitory computer-readable storage media (devices) includes RAM,ROM, EEPROM, CD-ROM, solid state drives (“SSDs”) (e.g., based on RAM),Flash memory, phase-change memory (“PCM”), other types of memory, otheroptical disk storage, magnetic disk storage or other magnetic storagedevices, or any other medium which can be used to store desired programcode means in the form of computer-executable instructions or datastructures and which can be accessed by a general purpose or specialpurpose computer.

Further, upon reaching various computer system components, program codemeans in the form of computer-executable instructions or data structurescan be transferred automatically from transmission media tonon-transitory computer-readable storage media (devices) (or viceversa). For example, computer-executable instructions or data structuresreceived over a network or data link can be buffered in RAM within anetwork interface module (e.g., a “NIC”), and then eventuallytransferred to computer system RAM and/or to less volatile computerstorage media (devices) at a computer system. Thus, it should beunderstood that non-transitory computer-readable storage media (devices)can be included in computer system components that also (or evenprimarily) utilize transmission media.

Computer-executable instructions comprise, for example, instructions anddata which, when executed at a processor, cause a general-purposecomputer, special purpose computer, or special purpose processing deviceto perform a certain function or group of functions. In someembodiments, computer-executable instructions are executed on ageneral-purpose computer to turn the general-purpose computer into aspecial purpose computer implementing elements of the disclosure. Thecomputer executable instructions may be, for example, binaries,intermediate format instructions such as assembly language, or evensource code. Although the subject matter has been described in languagespecific to structural features and/or methodological acts, it is to beunderstood that the subject matter defined in the appended claims is notnecessarily limited to the described features or acts described above.Rather, the described features and acts are disclosed as example formsof implementing the claims.

Those skilled in the art will appreciate that the disclosure may bepracticed in network computing environments with many types of computersystem configurations, including, personal computers, desktop computers,laptop computers, message processors, hand-held devices, multi-processorsystems, microprocessor-based or programmable consumer electronics,network PCs, minicomputers, mainframe computers, mobile telephones,PDAs, tablets, pagers, routers, switches, and the like. The disclosuremay also be practiced in distributed system environments where local andremote computer systems, which are linked (either by hardwired datalinks, wireless data links, or by a combination of hardwired andwireless data links) through a network, both perform tasks. In adistributed system environment, program modules may be located in bothlocal and remote memory storage devices.

Embodiments of the present disclosure can also be implemented in cloudcomputing environments. In this description, “cloud computing” isdefined as a model for enabling on-demand network access to a sharedpool of configurable computing resources. For example, cloud computingcan be employed in the marketplace to offer ubiquitous and convenienton-demand access to the shared pool of configurable computing resources.The shared pool of configurable computing resources can be rapidlyprovisioned via virtualization and released with low management effortor service provider interaction, and then scaled accordingly.

A cloud-computing model can be composed of various characteristics suchas, for example, on-demand self-service, broad network access, resourcepooling, rapid elasticity, measured service, and so forth. Acloud-computing model can also expose various service models, such as,for example, Software as a Service (“SaaS”), Platform as a Service(“PaaS”), and Infrastructure as a Service (“IaaS”). A cloud-computingmodel can also be deployed using different deployment models such asprivate cloud, community cloud, public cloud, hybrid cloud, and soforth. In this description and in the claims, a “cloud-computingenvironment” is an environment in which cloud computing is employed.

FIG. 7 illustrates a block diagram of an example computing device 700that may be configured to perform one or more of the processes describedabove. One will appreciate that one or more computing devices such asthe computing device 700 may implement the merchant system 102. As shownby FIG. 7, the computing device 700 can comprise a processor 702, amemory 704, a storage device 706, an I/O interface 708, and acommunication interface 710, which may be communicatively coupled by wayof a communication infrastructure. While an example computing device 700is shown in FIG. 7, the components illustrated in FIG. 7 are notintended to be limiting. Additional or alternative components may beused in other embodiments. Furthermore, in certain embodiments, thecomputing device 700 can include fewer components than those shown inFIG. 7. Components of the computing device 700 shown in FIG. 7 will nowbe described in additional detail.

In one or more embodiments, the processor 702 includes hardware forexecuting instructions, such as those making up a computer program. Asan example, and not by way of limitation, to execute instructions, theprocessor 702 may retrieve (or fetch) the instructions from an internalregister, an internal cache, the memory 704, or the storage device 706and decode and execute them. In one or more embodiments, the processor702 may include one or more internal caches for data, instructions, oraddresses. As an example, and not by way of limitation, the processor702 may include one or more instruction caches, one or more data caches,and one or more translation look aside buffers (TLBs). Instructions inthe instruction caches may be copies of instructions in the memory 704or the storage 706.

The computing device 700 includes memory 704, which is coupled to theprocessor(s) 702. The memory 704 may be used for storing data, metadata,and programs for execution by the processor(s). The memory 704 mayinclude one or more of volatile and non-volatile memories, such asRandom Access Memory (“RAM”), Read Only Memory (“ROM”), a solid statedisk (“SSD”), Flash, Phase Change Memory (“PCM”), or other types of datastorage. The memory 704 may be internal or distributed memory.

The computing device 700 includes a storage device 706 that includesstorage for storing data or instructions. As an example, and not by wayof limitation, storage device 706 can comprise a non-transitory storagemedium described above. The storage device 706 may include a hard diskdrive (HDD), a floppy disk drive, flash memory, an optical disc, amagneto-optical disc, magnetic tape, or a Universal Serial Bus (USB)drive or a combination of two or more of these. The storage device 706may include removable or non-removable (or fixed) media, whereappropriate. The storage device 706 may be internal or external to thecomputing device 700. In one or more embodiments, the storage device 706is non-volatile, solid-state memory. In other embodiments, the storagedevice 706 includes read-only memory (ROM). Where appropriate, this ROMmay be mask programmed ROM, programmable ROM (PROM), erasable PROM(EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM(EAROM), or flash memory or a combination of two or more of these.

The computing device 700 also includes one or more input or output(“I/O”) devices/interfaces 708, which are provided to allow a user toprovide input to, receive output from, and otherwise transfer data toand receive data from computing device 700. The I/O devices/interfaces708 may include a mouse, a keypad or a keyboard, a touch screen, acamera, an optical scanner, network interface, modem, other known I/Odevices or a combination of such I/O device/interfaces. The touch screenmay be activated with a stylus or a finger.

The I/O devices/interfaces 708 may include one or more devices forpresenting output to a user, including, but not limited to, a graphicsengine, a display (e.g., a display screen), one or more output drivers(e.g., display drivers), one or more audio speakers, and one or moreaudio drivers. In certain embodiments, the I/O interface 708 isconfigured to provide graphical data to a display for presentation to auser. The graphical data may be representative of one or more graphicaluser interfaces and/or any other graphical content as may serve aparticular implementation.

The computing device 700 can further include a communication interface710. The communication interface 710 can include hardware, software, orboth. The communication interface 710 can provide one or more interfacesfor communication (such as, for example, packet-based communication)between the computing device 700 and one or more other computing devicesor networks. As an example, and not by way of limitation, thecommunication interface 710 may include a network interface controller(NIC) or network adapter for communicating with an Ethernet or otherwire-based network or a wireless NIC (WNIC) or wireless adapter forcommunicating with a wireless network, such as a WI-FI. The computingdevice 700 can further include a bus 712. The bus 712 can comprisehardware, software, or both that couples components of computing device700 to each other.

The foregoing specification is described with reference to specificexample embodiments thereof. Various embodiments and aspects of thedisclosure are described with reference to details discussed herein, andthe accompanying drawings illustrate the various embodiments. Thedescription above and drawings are illustrative and are not to beconstrued as limiting. Numerous specific details are described toprovide a thorough understanding of various embodiments.

The additional or alternative embodiments may be embodied in otherspecific forms without departing from its spirit or essentialcharacteristics. The described embodiments are to be considered in allrespects only as illustrative and not restrictive. The scope of theinvention is, therefore, indicated by the appended claims rather than bythe foregoing description. All changes that come within the meaning andrange of equivalency of the claims are to be embraced within theirscope.

The embodiments of the disclosure described above and illustrated in theaccompanying drawing figures do not limit the scope of the invention,since these embodiments are merely examples of embodiments of theinvention, which is defined by the appended claims and their legalequivalents. Any equivalent embodiments are intended to be within thescope of this invention. Indeed, various modifications of the presentdisclosure, in addition to those shown and described herein, such asalternative useful combinations of the content features described, maybecome apparent to those skilled in the art from the description. Suchmodifications and embodiments are also intended to fall within the scopeof the appended claims and legal equivalents.

We claim:
 1. A computer-implemented method of managing states of useraccounts in connection with providing access to software over a network,the method comprising: enabling a purchase of a software as a serviceproduct through a provisional account without requiring creation of afull user account without requiring creation of a full user account;receiving a request associated with a user identifier, to access thesoftware as a service product; determining that the user identifier isassociated with the provisional account and preventing use of thesoftware as a service product through the provisional account, despitethe purchase of the software, by blocking one or more of a download ofthe software as a service product or operation of the software as aservice product through the provisional account; receiving a usercredential for the provisional account; in response to receiving theuser credential, converting the provisional account into a permanentaccount associated with the user identifier, the user credential, andthe purchase of the software as a service product; and enabling use ofthe software as a service product through the permanent account bypermitting one or more of the download of the software as a serviceproduct or operation of the software as a service product through thepermanent account.
 2. The method of claim 1, wherein enabling use of thesoftware as a service product through the permanent account comprises:receiving a subsequent request to access the software as a serviceproduct, the subsequent request being associated with the useridentifier; and querying an identification system and comparing the useridentifier with preexisting accounts to determine that the useridentifier is associated with a preexisting permanent account.
 3. Themethod of claim 2, wherein determining that the user identifier isassociated with the provisional account comprises querying theidentification system and comparing the user identifier with preexistingaccounts to determine that the user identifier is associated with apreexisting provisional account.
 4. The method of claim 2, whereinconverting the provisional account associated with the user identifierinto the permanent account comprises: removing a provisional identifierfrom the provisional account within the identification system;associating a permanent identifier with the provisional account withinthe identification system to create the permanent account; andassociating the user credential with the permanent account.
 5. Themethod of claim 1, wherein enabling use of the software as a serviceproduct through the permanent account comprises enabling a download ofthe software as a service product.
 6. The method of claim 1, whereinenabling purchase of the software as a service product without requiringcreation of a full user account comprises enabling purchase of thesoftware as a service product without requiring a password.
 7. Anon-transitory computer readable storage medium comprising instructionsthereon that, when executed by at least one processor, cause a computersystem to: enable a purchase of a software as a service product througha provisional account without requiring creation of a full user accountwithout requiring creation of a full user account; receive a requestassociated with a user identifier, to access the software as a serviceproduct; determine that the user identifier is associated with theprovisional account and preventing use of the software as a serviceproduct through the provisional account, despite the purchase of thesoftware, by blocking one or more of a download of the software as aservice product or operation of the software as a service productthrough the provisional account; receive a user credential for theprovisional account; in response to receiving the user credential,convert the provisional account into a permanent account associated withthe user identifier, the user credential, and the purchase of thesoftware as a service product; and enable use of the software as aservice product through the permanent account by permitting one or moreof the download of the software as a service product or operation of thesoftware as a service product through the permanent account.
 8. Thenon-transitory computer readable storage medium of claim 7, wherein theinstructions, when executed by the at least one processor, cause thecomputer system to enable purchase of the software as a service productwithout requiring creation of a full user account by enabling purchaseof the software as a service product without requiring a password. 9.The non-transitory computer readable storage medium of claim 7, whereinthe instructions, when executed by the at least one processor, cause thecomputer system to enable use of the software as a service product by:determining that the user identifier is associated with the permanentaccount; and enabling a download of the software as a service product inresponse to determining that the user identifier is associated with thepermanent account.
 10. The non-transitory computer readable storagemedium of claim 7, further comprising instructions that, when executedby the at least one processor, cause the computer system to request theuser credential in response to creation of the provisional account. 11.The non-transitory computer readable storage medium of claim 10, whereinthe instructions, when executed by the at least one processor, cause thecomputer system to request the user credential by sending an emailrequesting a creation of the user credential in response to the purchaseof the software as a service product.
 12. The non-transitory computerreadable storage medium of claim 11, wherein the instructions, whenexecuted by the at least one processor, cause the computer system torequest the user credential by providing a request within a confirmationwebpage associated with the purchase of the software as a serviceproduct.
 13. The non-transitory computer readable storage medium ofclaim 7, further comprising instructions, when executed by the at leastone processor, cause the computer system to receive a request topurchase the software as a service product from a first client device,wherein receiving the user credential comprises receiving the usercredential from a second, different client device.
 14. Thenon-transitory computer readable storage medium of claim 7, wherein theinstructions, when executed by the at least one processor, cause thecomputer system to enable use of the software as a service productthrough the permanent account by enabling a download of the software asa service product.
 15. A system for managing states of user accounts inconnection with providing access to software over a network, the systemcomprising: at least one server; and a non-transitory computer readablestorage medium comprising instructions that, when executed by the atleast one server, cause the system to: enable a purchase of a softwareas a service product through a provisional account without requiringcreation of a full user account without requiring creation of a fulluser account; receive a request associated with a user identifier, toaccess the software as a service product; determine that the useridentifier is associated with the provisional account and preventing useof the software as a service product through the provisional account,despite the purchase of the software, by blocking one or more of adownload of the software as a service product or operation of thesoftware as a service product through the provisional account; receive auser credential for the provisional account; in response to receivingthe user credential, convert the provisional account into a permanentaccount associated with the user identifier, the user credential, andthe purchase of the software as a service product; and enable use of thesoftware as a service product through the permanent account bypermitting one or more of the download of the software as a serviceproduct or operation of the software as a service product through thepermanent account.
 16. The system of claim 15, further comprising:memory comprising an identification system that maintains a mappingbetween user identifiers and a status as provisional accounts orpermanent accounts.
 17. The system of claim 16, wherein theinstructions, when executed by the at least one server, cause the systemto determine that the user identifier is associated with the provisionalaccount by querying the identification system to compare the useridentifier with preexisting accounts to determine that the useridentifier is associated with the provisional account.
 18. The system ofclaim 15, further comprising instructions that, when executed by the atleast one server, cause the system to: receive a request, associatedwith the user identifier, to download the software as a service product;determine that the user identifier is associated with the permanentaccount by querying the identification system to compare the useridentifier with preexisting accounts to determine that the useridentifier is associated with the permanent account; and enable thedownload of the software as a service product.
 19. The system of claim15, wherein the instructions, when executed by the at least one server,cause the system to convert the provisional account associated with theuser identifier into the permanent account by: removing a provisionalidentifier from the provisional account within the identificationsystem; associating a permanent identifier with the provisional accountwithin the identification system to create the permanent account; andassociating the user credential with the permanent account.
 20. Thesystem of claim 15, further comprising instructions that, when executedby the at least one server, cause the system to: issue an access tokenin response to enabling purchase of the software as a service productthrough the provisional account without requiring creation of the fulluser account; wherein the access token is limited to a web browsersession within which the software as a service product was purchased,and wherein the access token provides limited access to the software asa service product.